>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. 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? - Too busy driving to stop for gas! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
