This is in no way a personal comment on Tom's experience. 'What a programmer is supposed to do' is avoid stupid code. We were once tasked with finding the bottleneck in a fairly mundane VSAM application. It ran horribly, consuming scads of both CPU and wall clock. It didn't take long using an OTS product to discover that for every single I/O, the cluster was being opened and closed again even though nothing else happened in the meantime. Simply changing that logic slashed resource utilization.
In another case, we were on the verge of upgrading a CEC when the application folks themselves discovered a few grossly inefficient SQL calls. Fixing those calls dropped overall LPAR utilization dramatically. What Tom and I are both saying is that focus on instruction timing should be seen as more of an avocation than a serious professional pursuit. Like playing with model trains at the expense of improving actual rail systems. It's interesting, but not much real business depends on the outcome. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Tom Brennan > Sent: Thursday, December 24, 2015 10:52 AM > To: [email protected] > Subject: [Bulk] Re: Is there a source for detailed, instruction-level performance > info? > > Farley, Peter x23353 wrote: > > So what is an ordinary programmer to do? > > Years ago I guess I had nothing to do so I wrote a program that hooked into > various LINK/LOAD SVC's and recorded the load module name (like Isogon and > TADz do). That huge pile of data ended up on a tape and I wrote some code to > scan the tape for a particular module, to find out who was using it and how > often. > > The scan took forever, so I worked quite a bit trying to make the main loop > more efficient. Co-worker Stuart Holland looked at my logic and quickly > switched it to using a hashing lookup algorithm, making it run probably a > thousand times faster. Oops :) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
