Disassembler
in [Cobol]
|
From: Howard Brazee on 1 Mar 2006 13:06 On Wed, 01 Mar 2006 12:46:17 -0500, CG <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote: >This discussion has deteriorated to to the point of absurdity. When the >attitude appears to be, "My mind's made up, do not confuse me with >facts." it is time to quit! I'm done! Seeing that you didn't appear to read what I wrote, and you claimed that I didn't read what you wrote - it appears that your are correct in the above.
From: Pete Dashwood on 1 Mar 2006 14:35 "Howard Brazee" <howard(a)brazee.net> wrote in message news:67n802lf167v5u9jf68n10tjoavmrnsjp2(a)4ax.com... > 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^) Hahaha! Fair comment , Howard. I should state in passing that while I am strongly opposed to maintaining source code, patching object code is simply NOT an option. We used to do this in the late 60s when it took 45 minutes to compile COBOL on a NCR 315 that was tape based. We stopped doing it then when we found the horrors it caused, and I have nio intention of doing it now... Obviously, my response to the above would be not to develop programs where it is necessary to "adjust the address being used." And I am not saying that people who already have a certain environment can drop it overnight and start over with a component based solution. I am arguing for what will be a hypothetical and unattainable solution to many here. If the idea percolates through, then maybe some new developments will apply some of these concepts, and encapsulation and modularization will be attempted, even if no-one goes as far as OO and component wrapping. Maybe some of the sites that are moving to Java will consider writing beans that don't get modified. These are the best outcomes I can reasonably hope for, but it's fun trying :-) Pete.
From: Pete Dashwood on 1 Mar 2006 14:41 <docdwarf(a)panix.com> wrote in message news:du1nsi$p2f$1(a)reader2.panix.com... > In article <1141137619.797762.312570(a)u72g2000cwu.googlegroups.com>, > Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >> >>Pete Dashwood wrote: >>> <ozzy.kopec(a)gmail.com> wrote in message >>> news:1141046648.949404.165450(a)v46g2000cwv.googlegroups.com... >>> > Pete Dashwood wrote: >>> >>> 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 :-) >> >>I worked in a place where an operator dropped a whole tray of punched >>jcl cards (and successfully mixed them quicker than a poker dealer >>could have done). > > Oh, I *cannot* resist... > > 000100 AND WITH THESE AND OTHER INSTANCES IN MIND WE SHOULD, THEREFORE, > 000200 MAKE SURE THAT ALL CODE IS BACKWARDSLY-COMPATIBLE WITH SUCH > 000300 LIMITATIONS... JUST BECAUSE I HAVEN'T WORKED WITH A PUNCHED DECK > 000400 IN DECADES IS NO REASON NOT TO 'JUST IN CASE' THINGS, RIGHT? > > DD > Cheap shot, Doc. When writing COBOL it is necessary to use level numbers anyway. Why shouldn't they also assist in the (today) extremely unlikely event that the source needs to be recreated from a listing? I have worked on many sites and no-one has ever asked why I start levels at 12. It isn't problematic because there is room to insert other levels if required. It isn't about 'just in case' anyway. It is about the habits of a lifetime, which do no harm... Pete.
From: Pete Dashwood on 1 Mar 2006 14:51 "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1141137034.249009.40630(a)p10g2000cwp.googlegroups.com... > 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. > Anyone who is in the business of developing components will provide a help file with each one. When I was doing it, I often spent more time writing the help file than I did writing the component code. I found that other component developers who I was in contact with did the same. Anyone purchasing a third party componet has a right to expect it to be fully documented as I described. If you intend to use the components that are part fo your Operating system, these are, obviously, not documented. You use a piece of software called an Object Browser and it will show all the Methods and Properties and the interface. This is less satisfactory than a full help file, but I haven't found a case yet where I couldn't interface to an object with a little trial and error. People usng the Windows API are, in effect, doing this every day. Instead of using an Object Browser they are relying on the interface documentation provided in the SDK or by a third party. The answer to your question is that you don't buy them in as an add-on. They are either provided or ou deduce them with an Object Browser. Pete.
From: Pete Dashwood on 1 Mar 2006 14:57
"CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:41d3d$4404e7ff$453db2dd$1883(a)FUSE.NET... > Howard Brazee wrote: >> On Mon, 27 Feb 2006 14:24:13 -0500, CG >> <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote: >> >>>>> If you prefer, call it a DisCOBOLER instead of a DisASSEMBLER. >>>> I think the term traditionally used is "decompiler". >>> Yeh! I thought about that, but Pete seemed so hung up on the specific >>> language, that seemed more to the point. >> >> I suppose you could decompile code into just about any language you >> want. The more optimized the code, the more useless the decompiled >> results. > You seem to insist on ignoring [or just being ignorant of] the fact that > this technology guarantees to create COBOL code that will produce exactly > the same output as the object code. In fact, I believe that the new COBOL > source, when compiled, will normally produce exactly the same object code > _assuming_ you have the same version/release/level/etc. of the compiler > that produced the original. If the code was optimized before _and_ you > indicate that the re-compile is to optimize the new code, it will be the > same. Therefore, the decompiled COBOL code is exactly as useful or > useless as it would be if you had the original source code. If you still > consider this code to be useless, then I assume your process is always to > trash every source program as soon as you compile it. That is the essence > of what you are proposing. I really cannot understand your logic! I can. Howard is expressing the same reservation as I am. You seem to thnk that we are hung up or ignorant because we disagree with you or question the approach. No one is disputing that the compiled code will do the same as the old code. The point you seem to be missing is that the there is an ongoing maintenance requirement and it is easier to maintain code you wrote yourself, than code written by a tool. Instead fo posting heated responses, why not calm down and consider what we are saying? Pete. |