You shouldn't be looking at high CPU utilization but at total CPU usage
and EXCP counts for the job step (freely available from the usual
IEFACTRT exits). High CPU utilization could be a sign of a very
efficient and well tuned program, or a sign of gross choice of internal
algorithms. Bottom line though, if total consumption is not enough to
be significant in your shop, or to adversely affect other important
work, or to cost more than the user end-user is willing to pay, it may
not be worth pursuing.
If the job is causing problems either from excessive CPU usage or
excessive I/O, the cheapest thing to check and fix is I/O tuning since
in many cases this is just a JCL change. If EXCPs on any DD is high
(say 10K EXCPs and up), check that this is reasonable based on the
number of records and blocks in the file. For sequential DASD files
check for the obvious - poorly blocked or unblocked records. If a
sequential file is humongous, requesting enough buffers for full
cylinder or at least multi-track I/O may reduce overhead. For VSAM,
BUFNI and BUFND should always be specified, as the defaults are
inadequate for either sequential or random processing. In extreme cases
you may want to trying using BLSR. I have seen cases where a factor of
10-100 reduction in EXCP's and CPU has been achieved simply by adding
appropriate buffering to a VSAM file. IDCAMS LISTCAT before and after a
run is your friend for detecting VSAM abuse.
If you have to go down to the level of program code, then look for the
obvious again: Arrays being repeatedly searched, especially serial
search (it's incredible how much CPU can be used by a serial search of
even a relatively small array of 10-20 elements if you do it 100,000
times). I have seen extreme cases where a corporate want-a-be
programmer had actually written COBOL code using a serial search of a
100,000 element table! Even a binary search (SEARCH ALL) of a large
array of several 1000 elements is radically less efficient than a hash
table lookup if you are going to do it 1,000,000 times. Another big
problem (which will also show up in your EXCP data) is repeated look up
of the same data using a VSAM file as a table when an internal table is
more appropriate. A strong clue to this kind of behavior is a VSAM file
with an EXCP count orders of magnitude larger than the total number of
records in the file!
Frequently the biggest savings are made by taking a totally different
approach to the problem, but when dealing with applications that are not
your responsibility one would rather not get down to that level.
McKown, John wrote:
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan
Sent: Thursday, October 12, 2006 9:06 AM
To: [email protected]
Subject: Re: Curiousity: CPU % for COBOL program
Without the souce code I can't make any intelligent
suggestions. However, if you can find a copy of "The Elements of
Programming Style" it will give several examples of "bad" vs
"good" code and how to get from here to there.
IIRC, at one time there were (at least) three versions. One
each for COBOL, FORTRAN, and ?????
HTH,
Thanks. I guess I was asking because I don't have an automated way to
check for "bad" coding. And I was wondering if it was even worth my
time. If a high CPU utilization is "normal", then it would likely be a
waste of time to "desk check" the code. But if high CPU utilization is
sufficiently "abnormal", then it might be worth my time (and salary) to
do some "spot checks" of code and write a report to management.
One that would likely cause the programmers to hate me even more. They
already don't like me becase I now almost always require a "service
desk" ticket to do any work. But I can charge time to those tickets,
which proves my salary is worth paying. Why it is "easier" to walk to my
desk and ask me to do something than to write a email to the help desk
to open a ticket is beyond me. Perhaps because they don't want it known
how often they ask for our services? Speculation.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
