Disassembler
in [Cobol]
|
From: CG on 27 Feb 2006 13:51 Michael Mattias wrote: > "Peter Lacey" <lacey(a)mts.net> wrote in message > news:4403301A.2400BA98(a)mts.net... >> Pete Dashwood wrote: >> >>> Ah, the joys of maintaining source... :-) >> Don't start that again! It isn't every shop that has the luxury of no >> inherited programs. Are you also saying that compiled objects never get >> lost????? > > Worse: The source code in the 'official, sacred, controlled' archive is NOT > the source code for the compiled program. > > I think I'd rather start over than discover that the hard way. (again). > > MCM Quite the contrary: "The truth only exists in the code that goes into production every night!" I use this in virtually every presentation that I do. And, I have war stories to back it up from when, for example, a project manager insisted that a component was PL/I and had the source to 'prove it' BUT their production run-time library clearly showed that the code was an Assembler component with no resemblance to the expected logic. And, for very old code [We often see code that has not been compiled for 25 years or more.], if you do not know what the logic is, how do you propose to 'start over'? A fresh COBOL source program that, if recompiled, produces the exact results as the ancient executable is invaluable. Maybe in your ideal world, you can start over. But [again], the real world is not that nice.
From: CG on 27 Feb 2006 13:54 Pete Dashwood wrote: > > > "Peter Lacey" <lacey(a)mts.net> wrote in message > news:4401D1AE.578753D3(a)mts.net... >> 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.
From: CG on 27 Feb 2006 13:59 ozzy.kopec(a)gmail.com wrote: > Pete Dashwood wrote: >> 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. >> > Had a bud who's boss had them print out the source for every COBOL > program they had. They did incremental and full backups, but sure > enough after a hard drive crash they were missing a few programs. The > secretary hand entered the code from the printed listings so for once a > boss had a good idea :0) > But, this tool/service would have accomplished the same thing mechanically... That is the point. Now, if the HD contained both the executable and the source, listings are nice to have. In most cases, I do not trust listings unless they can be guaranteed to be the last listing by matching them with the executable. This is especially true if your listing does not have the option turned on to list the compiler options used. Different compiler options, even with the same source code can produce different results.
From: CG on 27 Feb 2006 14:05 Keith Lowe wrote: > "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message > news:1140879796.171911.152550(a)e56g2000cwe.googlegroups.com... >> Reading in comp.lang.asm370 I came across the following item which may >> be of some interest: >> >> <QUOTE> >> >> On Fri, 10 Feb 2006 13:54:57 -0500, Gilbert Saint-Flour wrote: >> <usenet5...(a)yahoo.com> wrote: >>> I found this page by accident a moment ago: >>> > http://patents.nimblewisdom.com/patent/5946484-Method-of-recovering-source-code-from-object-code >>> It's a patent issued in 1999 by the USPTO for a disassembler, which >>> wasn't a >>> new concept back then (I've written my first disassembler in 1982). >> >>> The problem is that the language of patents is so arcane that it's >>> difficult >>> to spot the original elements of this patent, or if there's any >>> originality >>> in it at all. Hopefully, one of you will dig something up. >> >> >> It appears to be more than just a dissassembler, based on the generated >> >> assembly code it looks for known patterns charateristic of the IBM >> Cobol >> compiler and attempts to symthesize the Cobol source, as nearly as I >> can >> tell in 5 minutes. But this has been done for many years, I am not >> sure >> what is novel here. >> >> </QUOTE> >> >> Perhaps there will soon be an answer to the perennial "Where can I find >> a cobol disassembler?" > > > Apologies if this is an obvious question.... but where can I find a cobol > disassembler ? I've read the instructions and I am none the wiser !!! > > Keith Contact Jim Rahm, Source Recovery Company: http://www.source-recovery.com/ or more direct: http://www.source-recovery.com/srcn-contactus.html [Feel free to tell him where you got the reference.] Note: I have no direct involvement or interest in them. I have just worked with Jim off and on for the last ten years.
From: Oliver Wong on 27 Feb 2006 14:17
"CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:b890d$44034ace$453db2dd$13218(a)FUSE.NET... > 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. I think the term traditionally used is "decompiler". - Oliver |