Re: FORTRAN reverse engineering
Can't answer your question but it reminds me of a long-standing conjecture of mine: I wonder if compilers plant idiomatic machine code - from which higher-level constructs can be garnered. I would expect optimising (prefer improving) compilers would defeat that. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Itschak Mugzach imugz...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 18/04/2015 17:46 Subject:FORTRAN reverse engineering Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I have three (quit complex) FORTRAN load modules which I do not have the source code of. I Know the Source company, but they deal with Cobol, and I need Fortran. Any idea how to reverse engineering the load modules? ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FORTRAN reverse engineering
All I can suggest is the following: - Run an AMBLIST to find out how many CSECT names there are in each of your LMODS. - Disassemble each CSECT in turn and then try to figure out what Fortran source code generated it. I did come up against a similar problem more than 20 years ago, caused by a loop in some Fortran code from a 3rd party ISV and executing in its own address space. The ISV could not identify what caused the loop (it happened at random) and would not release the source code either. I tracked down the start/end offsets of the loop in the LMOD from a full system trace, called in the ISV and asked them to recompile their source with an assembly listing (compiler 'LIST' option?) From this I could then match the object code in the dump with the Fortran assembly listing, and thus fix the problem. You could also try XDC'ing your LMODs if that helps. Just my ha'pennyworth. Cheers, Chris Poncelet Itschak Mugzach wrote: I have three (quit complex) FORTRAN load modules which I do not have the source code of. I Know the Source company, but they deal with Cobol, and I need Fortran. Any idea how to reverse engineering the load modules? ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
Clark Morris wrote: Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields My understanding is that the currently supported descendants, i.e. EGL, don't behave this way. Let me see if I can re-thread the use case needle here, Clark, and please correct me if I'm wrong in any of these details. You're pointing out that, if a CSP or VisualAge Generator program needs to be recompiled, with Enterprise COBOL Version 5.1 and above the compiler option NUMPROC(NOPFD) is required since NUMPROC(MIG) is no longer available. NUMPROC(MIG) offered a performance advantage versus NUMPROC(NOPFD) with Enterprise COBOL 4.x and older compilers. You're requesting that the compiler development team consider implementing NUMPROC(MIG) in Enterprise COBOL 5.x. Failing that, technical alternatives include: 1. Using NUMPROC(NOPFD); 2. Using Enterprise COBOL 4.2 only for these cases (when recompiling CSP and/or VisualAge Generator code); 3. Upgrading to IBM EGL. To ask a couple hard questions here: A. What would be, in your estimation, the net performance outcome using NUMPROC(NOPFD) with Enterprise COBOL 5.2 versus NUMPROC(MIG) with Enterprise COBOL 4.2, keeping in mind that Version 5.2 should already perform better than Version 4.2, other things being equal? Do you have any measurements suggesting otherwise that you could offer? Then, carrying that estimate forward, what percentage of workload would CSP/VisualAge Generator represent during the peak utilization interval? My informal observation is that there are indeed many shops still running CSP and/or VisualAge Generator code that they haven't yet recompiled using the supported EGL tool chain. (Many recompile when the opportunity arises, when normal code maintenance takes them there.) However, I haven't run into any shop yet where CSP and/or VisualAge Generator programs represent a significant fraction of peak utilization workload, most likely because keeping current with EGL already offered performance improvements, even before Enterprise COBOL 5.x. B. Relatedly, how often are customers recompiling CSP and/or VisualAge Generator programs nowadays, and what's your view of the trend? C. This is a rather odd case where there's a pair of compilers, roughly speaking: CSP and/or VisualAge Generator (that generate COBOL source code from the 4GL source), then the COBOL compiler. Thus far IBM has maintained backward compatibility so that customers can upgrade these compilers on different release schedules, and that's still true: there's a functionally correct option in Enterprise COBOL 5.2 technically compatible with unsupported CSP and VisualAge Generator. But did IBM have to do even this? Isn't it reasonable that if a customer is going to maintain one unsupported compiler (or code pre-processor, more precisely) in their environment, at some point in the future they might also have to maintain a corresponding older, second compiler as part of the chain if they adopt that particular approach to keeping CSP and/or VisualAge Generator? I'm sensitive to the fact the compiler teams undoubtedly have a long list of feature enhancement requests. Support for 64-bit data objects would get my vote, as an example. Given that reality, I'm trying to draw out just how important NUMPROC(MIG) would be. I'm not convinced it's that important yet given what seem to be the facts, but I keep an open mind. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On 18 Apr 2015 16:24:30 -0700, in bit.listserv.ibm-main you wrote: Mr. Ross, Is there going to be a corresponding PACKCHECK compiler option? It is=20 We have no plans for one, but we are very open to suggestions. I have wondered for years how a customer could actually migrate from NUMPROC(NOPFD) to NUMPROC(PFD), and something like that would help. Please submit an RFE (Request for Enhancement) at https://www.ibm.com/developerworks/rfe/?PROD_ID=698 very difficult to locate all of the assembler code that took liberty in=20 fixing positive pack decimal fields with a sign of F instead of=20 determining if the result field was signed or not. After all everybody=20 would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,=20 and ZAP etc.) to access/process a pack decimal field! Who would have=20 ever guessed that one of the future compilers would be smart enough to=20 make a determination/assumption that you could just use a compare=20 logical character instruction (CLC) to determine equality between two=20 pack decimal fields? Or even that we might avoid packed-decimal instructions completely for processing packed-decimal data! (we use DFP instructions when more efficient) Or, should we just take the performance hit and use NUMPROC(NOPFD) for=20 the life of COBOL? NMost cusotmers use NUMPROC(NOPFD) and it is not much of a hit for most. Maybe we could petition for the reinstatement of NUMPROC(MIG) You could ask, and we would most likely say no. NUMPROC(MIG) was supposed to be a temporary solution for customers migrating from OS/VS COBOL to VS COBOL II in the 1980s... Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields this means that all sites afflicted with these products are having the most efficient way of handling the packed and display numeric fields given the contortions of these products. I guess we are all wondering just how much anguish=20 NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial=20 to some of us and less overhead than NUMPROC(NOPFD). If I remember=20 correctly NUMPROC(MIG) only fixed signs on input and NUMPROC(NOPFD)=20 does additional sign fixing. I suspect that most sites have not done that much research into the 3 options and don't realize the effects of each. I fell into finding out by accident when I tried NUMPROC(PFD) back in the 1990's and promptly got a NOT NUMERIC on a packed field that had an F sign. Since this was production data it instantly became apparent that NUMPROC(PFD) was a non-started in that environment. The shop also had and used CSP 4.2 (compiles of the generated COBOL code had to be done NOOPTIMIZE because of the prolific GO TO statements among other problems). We have had only a handful of complaints, and several customers were embarrassed to discover that they were using NUMPROC(MIG) and only really thought about it when migrating to COBOL V5. They say they are going to go through the effort to migrate to NUMPROC(NOPFD). Most application management doesn't understand the technical tradeoffs and wouldn't understand why they would be taking a performance hit going to NUMPROC(NOPFD) from NUMPROC(MIG). Clark Morris Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
