Disassembler
in [Cobol]
|
From: Alistair on 27 Feb 2006 10:28 Pete Dashwood wrote: > > I still can't see much point in going to all the trouble of disassembling > code ifyou have the source. If you DON'T have the source, then disassembling > it is really not going to help much... Maybe, if it is absolutely Mission > Critical code and you really MUST amend it. Personally I wouldn't. I'd take > the opportunitiy to rewrite it. But then, in my case it would be component > based and I don't NEED the source anyway :-). > > Pete. > >> I may be misleading you slightly. The program that source-recovery.com uses reconstitutes the cobol code from the executable (disassembles first then pattern matches for code equivalent to assembled cobol verbs). If you have the fd then they use that to give "meaningful" data names to items ('Pete the delete' was well known for using PH1 and PH2 as variable names, being his initials). As for not needing the source if, as a new boy, you were asked to use a pre-existing component to provide a certain function, how would you know with what parameters to invoke it? unless you had perfect documentation (of which source code is the prime example).
From: Keith Lowe on 27 Feb 2006 10:43 "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
From: Michael Mattias on 27 Feb 2006 12:20 "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
From: Howard Brazee on 27 Feb 2006 12:30 On Mon, 27 Feb 2006 11:00:10 -0600, Peter Lacey <lacey(a)mts.net> wrote: >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????? We're moving towards a Java environment for much of our code. I went to modify a method and first did a search to determine where the code was copied - and found 161 copies of a file which I had created, which was copied by the trunk and branches and a bunch of places that I don't get. I'm told not to worry about it, but that's hard from my background. The code in these are not all the same. Vernor Vinge has a SF novel which includes people working as software archeologists, digging down through systems trying to clean up thousands of years of interactions.
From: Oliver Wong on 27 Feb 2006 12:49
"Howard Brazee" <howard(a)brazee.net> wrote in message news:lhd602hs3ie1rgrfbp0js4vm4kd13q0n9h(a)4ax.com... > On Mon, 27 Feb 2006 11:00:10 -0600, Peter Lacey <lacey(a)mts.net> wrote: > >>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????? > > We're moving towards a Java environment for much of our code. I went > to modify a method and first did a search to determine where the code > was copied - and found 161 copies of a file which I had created, which > was copied by the trunk and branches and a bunch of places that I > don't get. I'm told not to worry about it, but that's hard from my > background. > > The code in these are not all the same. Sounds like you're using a source version control system. These systems keep a copy of every version of the source code you've written. So if you've comitted 100 changes to the files, they'll be 100 copies of the file lying around[*]. "Branch" and "Trunk" are terms frequently used in such system. See: http://en.wikipedia.org/wiki/Version_control_system http://en.wikipedia.org/wiki/Concurrent_Versions_System http://en.wikipedia.org/wiki/Subversion_%28software%29 - Oliver [*] Actually, in practice, various compression mechanisms are used. For example, one "master copy" might get stored, and the other 99 files just describe the deviations from the master copy or from each other, rather than containing the whole file verbatim. |