</rant on> PMFJI here but this has become one of the most annoying and frustrating aspects of our business in the last decade or so. It SHOULD NOT be necessary to have "considerable statistical prowess" or have access to DCOLLECT output (which most normal application programmers DO NOT HAVE) or to have access to a statistical package like MXG or any other such beast in order to answer simple questions like "does machine X have enough CPU horsepower to run YYY instances of program ZZZ at the same time?" or "how much CPU and elapsed time will the new changes in program ZZZ consume when moved into production?". These are questions that a normally skilled professional application programmer ought to be able to provide a reasonable answer to -- but we cannot, because "it depends...".
I'm not advocating a return to the single-non-pipelined CPU days of yore, just for SOMEONE (not me since I am obviously not qualified) to come up with a REPEATABLE way to measure a program's real performance with only one or two production-level test runs. I should not have to waste my employer's scarce CPU resources to run a new or modified program ten or twenty times using production-quantity data volumes to get an "average" performance which turns out not to have ANY real relationship at all to the actual production performance.</rant off> Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, July 17, 2012 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Help with elementary CPU speed question Rob Scott has pointed you in the right direction. Worth emphasizing is that CP-SU ratios are most useful for botionally 'scientific' , CP-intensive applications. Many 'business' applications are I/O-bound, some of them--MFUs are the classic example--to the extent that shrinking CP processing to zero has little measurable effect upon residence time. In I/O bound situations CP-SU ratios may be irrelevant or, worse, misleading. This old distinction is often lost sight of here because mainframe 'scientific' processing does not figure much in our discussions. It remains important. More generally, useful performance analysis requires years of experience with a platform, its software, the use of appropriate measurement software, and considerable statistical prowess. Absent this skill set, it is easy to make a fool of oneself and all but impossible to make useful contributions. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
