Peter, If I was an application programmer (which I was when I got this assignment), I would certainly discuss with my manager whether or not this work was appropriate first. Reducing CPU time is a very labor and skill-intensive process, and one I have spent many years (forty-seven) doing. He should be willing to agree to this, and make a request of the appropriate systems personnel to do the work for you. If he is not willing to do this, I would certainly make him aware that this may be a lot of expense for naught.
However, if it was still deemed appropriate for political or other reasons to reduce CPU time on a particular program, I would use the tools you have. Strobe is an excellent tool, and I have used it many times to accomplish exactly the task you have been assigned. If you make the correct changes, they will reduce the CPU time no matter what the environment. The most effective reduction of CPU time, IMHO, is the elimination of unneeded instructions and services. There are almost always a lot of these in almost any program. Usually, this is all that is needed. Another valid question you ask is how to validate the results. I have a favorite of mine, which is to run five interleaved runs of both the old program (before changes) and the new program (after changes), preferably during a quiet time on the machine, if you have any. I try to avoid running under VM or on an LPAR which does not have dedicated physical processors, but sometimes that is unavoidable. I then throw out the high and low of each run, and take the means of the remaining data points from the joblogs, both TCB and SRB. This has usually proven to be a reliable method. This is not to say one does not run into surprises from time to time. I was bench-marking at a very large shop, stand-alone, on a dedicated eleven processor box. The CPU time was considerably higher than I had seen before. Running a Strobe-like product, the problem was isolated to IBM data space modules. I was stumped. A quick conference with Bob Rogers revealed the well-known (at least inside of IBM) issue...creating and destroying data spaces causes all of the other processors to be SIGPd and perform an UNBIND and BIND process, while the originating requestor spins. This is designed to purge the ALBs of other processors which might be affected. It does work, but it exacts a demanding price. Sixty-four bit is the answer. I also believe IBM is working on this issue to allow more intelligence in this processing. Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Tuesday, February 05, 2008 4:23 PM To: [email protected] Subject: 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 ---------------------------------------------------------------------- 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
