I'm not Jim Mulder but > Rather than tossing five different versions of the program onto the machine
Yes, your idea of measurement is superior, at least as a starting point. > when you say "despatch", I think "mail room" or "loading bay". As plain as > possible is fine with me. Perhaps not quite the official explanation but dispatch = your task getting control/usage of a CPU: the last time your program "woke up." I would say that if you are measuring the CPU time used in some large span of code including I/O then the CPU time figure will be pretty good. If you are measuring how long it took you to compute pi to ten digits, then you could conceivably end up with zero, because it was all computed since you "got" the CPU most recently. Perhaps others here have a strategy for forcing a new dispatch. Does the TIMEUSED macro force a dispatch? > "interruptible" instructions (like MVCL, I was told), are they "doing me in"? I would say not per se. They are interruptible precisely because they might take a long time, but the fact that they might be interrupted is not the problem. If you are doing lots of 200K moves, for example, then the problem is the moves, not the interruptions. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Tuesday, December 20, 2016 6:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL inline CPU timer Thanks Jim Mulder. <snip> If there's some way to make it more "accurate" for what I want, I'd be pleased. I'm "applications", so when you say "despatch", I think "mail room" or "loading bay". As plain as possible is fine with me. Perhaps-related question. "interruptible" instructions (like MVCL, I was told), are they "doing me in"? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
