Re: CPU time differences for the same job

Tom,

Your answer, though, betrays a system programmer (or perhaps just ISV)
point of view. The first thing is, application programmers are not
always permitted to "gather SMF records", even assuming they know what
they are and know how to find and use the tools needed to report on and
interpret them. In my shop, DCOLLECT and SMF archives are
RACF-protected from use by anyone except authorized personnel. I am
given to understand this is not uncommon, and may be an audit
requirement.

Management of development areas still are tasked with reducing the CPU
consumption and elapsed running times of their applications, regardless
of the "well known culprits" being addressed by IBM and ISV's. So they
task their programmers with that requirement, and I am asking what I as
an application programmer have available to me to measure my results
when I make source changes intended to improve performance.

Based on this thread, the JES-reported TCB and SRB usage (in JESMSGLG)
is unpredictably variable. Those numbers and the Strobe product the
only tools I have available to me.

In the larger scheme of sysplex-wide throughput and response time the
magnitude of application CPU usage may or may not matter, but if I'm
given the task to reduce those numbers for a particular application, I
need to know what reliable and unrestricted tools are available to
measure my results. It's very discouraging to be told "the tools you
depend on are unreliable and unpredictably variable".

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@xxxxxxxxxxx] On
Behalf Of Tom Harper
Sent: Tuesday, February 05, 2008 4:53 PM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: CPU time differences for the same job

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
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.

Relevant Pages

  • Re: Thinking assembly?
    ... I simply needs to understand the CPU and how it works, ... > understand the instructions, be a good and experienced programmer, ... assembly language is the machine's language (or, at least, ...
    (alt.lang.asm)
  • Re: How does this make you feel?
    ... >>>primitives to implement, say, a memcpy just as efficiently as microcode ... > The work is offloaded from the programmer in any case - this type of code ... library macros need updating for new CPU products, ... And designing such instruction such that they don't ...
    (comp.arch)
  • Re: Significant Pure Assembler Application In MASM ?
    ... probability for having, later, a Processor emulating, by ... your execution and data environment. ... so the poor low level programmer have to rewrite the same programme ... so define an assembly language for that cpu; so c or c++ compiler can ...
    (alt.lang.asm)
  • Re: Significant Pure Assembler Application In MASM ?
    ... probability for having, later, a Processor emulating, by ... your execution and data environment. ... so the poor low level programmer have to rewrite the same programme ... so define an assembly language for that cpu; so c or c++ compiler can ...
    (alt.lang.asm)
  • Re: CPU time differences for the same job
    ... I gathered SMF records and sorted them down by total CPU ... How is the normal application programmer who is tasked with reducing the ... significantly impact CPU consumption (sequential searches on large ... have the same priority as production environments, ...
    (bit.listserv.ibm-main)
Loading