CPU time measurements for individual statements are IMHO kind of useless, if you are not a compiler writer or machine architect. To know about the CPU usage of single statements, it is much easier to look at the instructions generated by the compiler.
Much more useful is the measurement of larger pieces of codes or the identification of "hot spots", where much CPU is consumed in little loops for example, which are executed very often. Two approaches: a profiling tool like STROBE, which observes the running TCB etc. and looks over a certain period of time, in which places of the code the PSW is running. So a distribution of the CPU time consumed over the whole code is generated, for example in 64 byte chunks granularity. This way it is possible to identify the locations in your program where most CPU is consumed. Another approach, which we use in a home grown tool: at certain points in the application, we called system functions like TIMEUSED to calculate the used CPU time for certain function calls. But this information is not printed immediately but instead stored into memory buffers and printed only at the end of the application, together with the number of executions etc. (Of course, if you have hundreds of function points in your application, which you want to measure, the handling of the memory buffer must be very fast - we used self-balancing trees to organize the time values for the different function points. And: it is necessary that the measurement activity can be activated from outside - DD-Name etc. - so that no code change is necessary. On the other hand: the CPU overhead for the test for the measurement activation has to be reduced to the absolute minimum.) This is done on some hundred testcases, together with the regression tests, and over time you can see, if new versions of the application have performance problems, compared to the prior version, and if so, you can act accordingly. That is, we are monitoring the performance of the application, but not only at the overall level, but also at the level of individual function points. If this is done regularly, you have an early warning system for potential performance problems in your application. Kind regards Bernd Am Donnerstag, 8. März 2012 17:03 schrieben Sie: > On 8 March 2012 10:17, Farley, Peter x23353 <[email protected]> wrote: > > AFAIK there are no free tools or programs you can write which can measure > > CPU time for each COBOL statement. You need to use a software tool like > > STROBE or CA-TRITUNE or one like them to get that kind of information. > > And presumably if COBOL has any sort of optimization at all, it will > in many cases be difficult to assign consumed CPU time to particular > statements. > > Tony H.
