On 25 Jun 2010 20:47:56 -0700, in bit.listserv.ibm-main you wrote: >>Your point that the language used for that "5%" doesn't matter is only partly >>true, IMHO. >>Knowing how to optimize the language that you or your management chose and >>knowing the "hot spots" to avoid helps avoid writing or correct bad code no >>matter the language used. > >Algorithms! >Algorithms! > >Bad code is bad code and good code is good code. > >But, in z/OS, when I've written bad code, I'm invoking ISV/IBM code, >inefficiently. > >When I've written good code, I've invoked the other stuff efficiently.
There also is the trick in knowing whether to use LE or system functions as opposed to doing the calculation in line and when in the overall scheme of things it matters. For example the COBOL functions to convert Gregorian dates to day year format and vice versa take far more CPU relatively than coding the conversion in line. READ x INTO y can be more costly than READ x, MOVE x-record into y when x-record is variable length or 1 of 5 different length records that can be read. The question is whether the inefficiency gets buried because of other issues or the overall volume makes the difference trivial. Critical path and response time issues then should focus the attention. The issue of intermodule overhead also becomes important. In some cases combining the code in the same module by using nested programs can have a significant impact. In others, it isn't worth the cost. > >HLASM or COBOL really doesn't matter. >That's just an implementation detail. > >It's only hot if you're calling services excessively. > >Even interest calculations call vendor code, even if it's just linkage to LE, >which you didn't write. > >I'm not saying that that 5% is trivial, but it only does business logic, as >important as that is. >But, everything else is vendor code. > >READ. PROCESS. WRITE. > >Plus initiation, allocate, open, close, de-allocate and terminate. > >Only one section is written by the user. > >The rest may seem like the user wrote it, but how much system code is invoked >by a simple open statement? > >Take care of your algorithms, and the language will tend to become secondary. > >The optimum language will be the one that your staff knows. > >And, before it's said, are languages like JAVA, or SAS, inefficient, or are >their runtime environments? > Interpreted languages always add a degree of inefficiency which may or may not be acceptable in a given environment. Clark Morris >- >Too busy driving to stop for gas! > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
