Thanks to those who responded. These were the results I got.

Step CPU MSecs     Gain     Changes
   0       28,051                      First version
   1         7,902           3.5x    Added COMP to make numeric fields
binary
   2          7,682          3.7x    1+ OPTIMIZE=1,SYNC32 (simple program,
not much to optimize)
   3          4,654           6.0x   1+2+ Replaced Divide with FUNCTION REM
   4             187          150x   1+2+3+ Replaced max from half to root
with same results

So in tuning a COBOL program we can gather that:
1. As Bob, Jerry,  Tom, & Johan  pointed out, doing math with ASCII fields
is very inefficient. However, this is by far the main way it is done. Why?
Originally one could not use the DISPLAY verb with COMP fields. Well you
could, but what got displayed was not very useful:) This greatly hampered
debugging, as well as occasionally causing the terminal to receive some
*interesting* escape sequences.
2. As Olav and Tom also responded regaurding the use of FUNCTION REM versus
DIVIDE, in general, if a built in function is available it will be far more
efficient than general code. Many of todays production programs were written
pre '85 so they had to do things the 'hard' way.
3. Perhaps the best gains as Johan & Tom pointed out, are had in
understanding the original intent of the program. In this case the fact that
the root is just as good as the half in results, but by far more efficient.
In real life production programs, this approach applies more to the database
access logic, but tuning for best Image performance is an entirely different
Friday Trivia subject:)

COBOL FOREVER!

TGIF

Mike Hornsby Co-founder/Chief Technical Officer
Beechglen Development Inc. (beechglen.com)
513-922-0509 [log in to unmask]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *