Disassembler
in [Cobol]
|
From: Pete Dashwood on 28 Feb 2006 07:12 <ozzy.kopec(a)gmail.com> wrote in message news:1141046648.949404.165450(a)v46g2000cwv.googlegroups.com... > 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) > Once long ago, but not in a distant galaxy, some of us wrote source code based on the premise that it might need to be re-entered (actually, re-punched into cards) from a listing. To try and make life easier for the punch girls (note deliberate political incorrectness; I never saw a man do this job, although most of us could use a hand punch prettty quickly) we left 'clues' in our COBOL source. The girls were aware that COBOL procedure statements started after column 11 and that procedure names started in column 8. They recognised comments and debug elements in 7, program source deck identifiers in 73 - 80, and line sequences in 1 -6. They used 'program' drums on their punch machines that allowed them to tab to these key columns instantly. Pretty straightforward. But the Data Division was more difficult. To this day I structure data definitions in COBOL as follows: 01 record level. 12 first-subfield. 15 first-subsubfield pic (whatever...). 12 next-subfield pic (whatever...). The level numbers indicate what column the data should start in. They knew that 01 levels had to be in 8 and pictures in 36 (the last was simply a local standard, based on what IBM did... :-)) I can think of at least two separate sites (and a number of occasions on both of them) where we were very glad to have source recreated from listings after decks of cards got shredded or minced in various readers or were destroyed by water after a storm where part of the roof was removed... Maybe your bud's Boss was an oldtimer like me :-) Pete. >
From: Pete Dashwood on 28 Feb 2006 07:24 "CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:6473a$44034c15$453db2dd$13503(a)FUSE.NET... > 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. No that is not the point. The tool/service you are touting would NOT recreate the source that was lost; it would recreate it's own interpretation of the machine code in a source code format. THAT is the point. While it may or may not be valuable to have this tool's interpretation of the machine code, (certainly better than having nothing at all), there are still inherent problems in maintaining this source on an ongoing basis. (Just as there are in maintaining any source on an ongoing basis. The difference being that source you wrote yourself is likely to be more familiar to you than source written by a tool...) But then, I would say that... :-) >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. > Your point regarding compiler options is a good one. However, if you lost your source and had something that might be able to recover at least the functionality of it, in source format, finding the right compiler options would be the least of your worries. And, in ancient times when I used to live in your universe, they were standard on most installations anyway. Pete.
From: Pete Dashwood on 28 Feb 2006 07:43 "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1141054122.657116.316160(a)e56g2000cwe.googlegroups.com... > > 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). ># Source code is only the prime example of documentation iif you are maintaining source code. The prime example of documentation for an object-only component is the Help file that documents its Methods, Events and Properties. This will also document the interface it implements, and what parameters are required, along with sample code for invoking it in various languages You register the component and consult the help file. As the component doesn't change, the help file doesn't either. It always documents what the component does. If you simply didn't know WHAT component to use, or what might be available, you would consult the site component register. (More and more sites are building them... they are pretty essential for serious component based design.) The register has a description of each component and can be searched using KWIC (Key Words in Context), which is like a free format text matching tool. You give it keywords and it searches the component descriptions and returns the sentence in which each word appears, and a link to that component description. Over the last couple of days I have been having great fun getting the Rational toolset to implement exactly this type of search. I have been building hooks into Clear Quest to make it scan certain free format descriptions and apply a regular expression to them that returns the sentence any match occurs in. These 'contexts' are then pushed to a screen, along with the key of the record each one was found in. This enables us to find cases where duplicate errors may have been raised by different teams. The component register uses exactly the same technique to help you find the component you need. (Seeing a keyword in context allows you to decide whether you are interested in THAT particular use of it or some other one...) Hope this helps. Pete.
From: Howard Brazee on 28 Feb 2006 09:25 On Wed, 1 Mar 2006 00:48:25 +1300, "Pete Dashwood" <dashwood(a)enternet.co.nz> wrote: >I agree. That's why I'm advocating NOT mantaining source code. It is a >highly error prone process that causes more harm than it heals... So when you have a big billing program and need to adjust an address being used, you start the requirement gathering to replace the program... Or maybe just patch the object code... 8^)
From: Alistair on 28 Feb 2006 09:30
Are these help files an integral part of the system or are they something that you have to buy-in as an add-on? I only ask coz I'm ignorant in OO. |