On 19 Feb 2014 03:48:24 -0800, in bit.listserv.ibm-main you wrote: >On Tue, Feb 18, 2014 at 5:20 PM, Shmuel Metz (Seymour J.) < >shmuel+ibm-m...@patriot.net> wrote: > >> In >> <of1dbe6dec.23eaa84d-on85257c83.0046f9a1-85257c83.0047a...@us.ibm.com>, >> on 02/18/2014 >> at 08:02 AM, Peter Relson <rel...@us.ibm.com> said: >> >> >So it's probably less about optimizing existing code (unless it's in >> >a loop) than about understanding what is best for your new code, >> >when the development and test costs of the choices are basically >> >the same. >> >> Generally what's best is what's most maintainable and most readable. >> > >Around here, that would likely translate into (1) convert it to COBOL or >(2) rewrite it to run on Windows, using .NET . Both of those are more >readable and maintainable __in this shop__. Yes, I'm joking a bit. Kind of.
With any supported COBOL compiler you have nested programs and multiple levels of COPY so that you could write an entire program in a COPY book that would have COPY statements in it. This allows the program to included in multiple programs thus eliminating much of the inter-module instruction overhead. The compiler may even do more sophisticated code elimination and optimization. In addition if many of the assembler routines were written to get around restrictions and difficulty of doing things in COBOL VS - the 1974 standard COBOL, those restrictions and difficulties may no longer exist. Reference modification and a number of other features in the newer compilers have made a major difference. Further, look at the 2002 standard and draft standards and see if the abilities to have bit manipulation, BIT and various FLOATING POINT usages including DECIMAL FLOATING POINT and various types of rounding including rounding to nearest even would allow your shop to eliminate even more assembler programs. Code that can easily be moved inline is code that doesn't incur inter-module overhead. I suspect that linked lists and queues are relatively easy. Also with LOCAL-STORAGE recursive routines can be written. I have used COBOL to manipulate the SMF 30 records among others so COBOL is more powerful than many here might realize. The 85 standard COBOL were a great leap forward. Many of the optimizations I did for a program using the COBOL VS would have been counterproductive with the VS COBOL V1.4 and the Enterprise COBOLs. Going through a shop's Assembler inventory to see which is worth converting to COBOL would enough fun to make me come out of retirement assuming financials could be worked out. Clark Morris ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
