On Feb 5, 2008, at 3:52 PM, Tom Harper wrote:
Peter,
The answer is: it may not matter. Some time ago I was asked to do
research to see if the installation I worked for could justify a COBOL
optimizer (this was a while back, but I believe same issues are true
today). I gathered SMF records and sorted them down by total CPU
consumed by PGM=program name in our installation for a month. The
results were very interesting, but I would be also interested to
know if
others have done this and what they found out.
What I found out was the following:
- About 30% of the CPU was consumed by SORT
- About 10% of the CPU was consumed by IEBGENER
- ...
- About 2% of the CPU was consumed by application COBOL programs.
The conclusion I drew was that even if you eliminated all of the CPU
used by application COBOL programs, the most one would save is 2%. We
declined to purchase the product.
It has been my personal experience that a similar, but perhaps
different
CPU profile exists in most shops (that is, a list of declining amounts
of CPU time). The products that use large amounts of CPU time are well
known, and a great deal of effort at IBM and ISVs has been expended to
work on this issue. To verify this, just do the same thing on your
particular program for all of the CPU it uses in a month. The small
amount may surprise you.
Additionally, a portion of the CPU time charged to your program may be
in doing services on your behalf, such as QSAM, various SVCs, etc.,
over
which you have some, but often times, little control.
Tom Harper
IMS Utilities Development Team
Neon Enterprise Software
Sugar Land, TX
Tom,
Most interesting observation (and probably accurate, IMO) What
doesn't show in your numbers and it would be somewhat difficult to
prove is that the sort numbers are understated because the COBOL(as
well as other High level languages) program can invoke the sort
underneath the covers. If you had the sort creating SMF recs then
maybe you could get a real number as to the number of sorts. This can
compound the issue as its difficult to separate out the amount of CPU
time done by COBOL type programs and sort programs.
(history alert). Way back in the 80's we had 2 4341's and we were
pinned against the wall with CPU time. The one system programmer
looked at the CAPEX product and said we could save X amount of CPU
time by getting it. I am very sure she did not do your number
crunching as I suggested (to the boss) she was not giving a full
picture. He told me to clam up and go with the program. I stood by
and watched all the program recompiles were done. A followup report
was never given to show savings. I told the boss not to get his name
to mixed up in the process. He ignored me. I got tired of the finger
pointing and suggested to the boss that he not wave the flag to much.
He stuck it out. I just sat silently by and watched the boss go down
in flames. He never spoke to me after that.
After he(my boss) left I started to produce simplistic reports (non
SAS) to management (first my management then programming management)
They liked the *SIMPLE* numbers I was providing but alas no graphs
(which makes management happy). They kept coming back for more and I
gave them as much or little detail as they wanted. When they wanted
graphs I told them no can do as you need SAS. I also suggested if
they wanted real pretty reports that they hire a capacity planner. I
was flabbergasted but they did hire one and he was pretty good not
great but good. When it came time for a CPU upgrade we got all our
ducks in a row and we went to Raleigh for Snapshot and we were one of
the very few companies that got everything right the first day and
then we could sit back and play what if. The capacity planner was the
first person they let go when the market took a tumble. The idiot
boss didn't like the guy because he had more say so in upgrading than
the VP did.
Ed
----------------------------------------------------------------------
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
