I had a similar story. On a 370/138 at an auto insurance company, the rating program (vendor supplied) would immediately "eat the machine". In those days, there was an actual CPU meter on the console. Whenever this job would run the meter "pegged" for the duration.
Basic logic was input pre-process call subroutine post-process output. I was asked to check into the performance of this program. Very quickly, I noticed that *ALL* fields were "USAGE DISPLAY". Without changing a single line of logic, the DISPLAY fields were changed to the appropriate internal representation (COMP, COMP-3,...) The program was no longer noticeable when it ran after the changes. It turns out that the following sequence of instructions was used for binary fields in display prior to the change. PACK CVB Perform operation CVD UNPACK (to store the result). Changing the fields to the correct internal representation reduce the sequence to: Perform operation The program logic caused the initial sequence to be executed 8 times for every numeric filed used in the program. PACK, UNPACK, and CVB, CBD are (or at least were) some of the slowest instructions on the processor. <snip> > Integer arithmetic should never be done with anything but binary integers. "What never?" One excuse might be when the only arithmetic to be performed is to add up "a column" of numbers and present the result. Converting to packed decimal, adding using the packed decimal instruction and then converting the total to the printable form might be an example of where staying with packed decimal is the more efficient. "Well, hardly ever!" To all following this topic Even before John Gilmore's assertion, I had in mind to tell a story concerning the relative efficiency of packed decimal. Forty years ago in the north-west of England, an IBM salesman was faced with losing one of his customers. Competition had muscled in and proposed a machine potentially more suited to the demands made on the customer's business - and their pocket. The salesman's response was to propose replacing the 360/30 with a 360/25 which I believe had only recently - at the time - been added to the 360 range, extending it "downwards" - ignoring - *obviously* - the 360/20! ...... remainder snipped </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
