On 06/25/2010 02:42 PM, Ted MacNEIL wrote: >> Whatever became of efficiency. > >> Years ago Bell Labs Management required all application programming be done >> in BAL. > > The myth that BAL is more efficient, is (in general) just that, a myth. > COBOL, with optimisation, is almost as efficient, and easier to maintain. > People costs are more than coding costs. > > In a z/OS environment, with access methods, online sub-systems, utilities, > and the like, less than 5% of the code running on the z/Box is user-written. > Complaining about the efficiency of BAL (or HLASM) is false economy. > > Write assembler where required; allow the technician to use whatever tools > they are comfortable with for the rest. > > IT is to improve the efficiency of people, NOT the reverse. > ... When implementing algorithms that are a good match for the language capabilities, high-level languages with a good optimizing compiler can certainly approach excellent Assembly code, or even greatly exceed Assembler efficiency when a more readable algorithm representation allows you to recognize and implement a more efficient approach to an application.
But here we are talking about a case of manipulating directory entries and internal content of an Operating-system-specific construct, a PDS. Higher-level languages like COBOL, that are deliberately designed to be machine-independent, provide no syntax to specify actions on that level. It just can't be done without depending at some point on code written in Assembler - either a local utility or some vendor utility. If there is a management concern that a local utility might break at some unknown point in the future with no one locally qualified to fix it, then look for alternatives to be sure it can be replaced if needed. But since it would take some major system maintenance to break something basic like this, this is not something likely to die over night with no prior warning. I concur with others that say it doesn't make sense to spend time and money to ditch something that is working satisfactorily just because it is written in Assembler code, unless and until it can be shown to fail at some future maintenance level of z/OS. -- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org ---------------------------------------------------------------------- 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
