Joined: 22 Apr 2006 Posts: 6258 Location: Mumbai, India
CPU time is the time for which the CPU was busy executing the task. It does not take into account the time spent in waiting for I/O (disk IO or network IO). Since I/O operations, such as reading files from disk, are performed by the OS, these operations may involve noticeable amount of time in waiting for I/O subsystems to complete their operations. This waiting time will be included in the elapsed time, but not CPU time. Hence CPU time is usually less than the elapsed time.
But in certain cases, the CPU time may be more than the elapsed time !When multiple threads are used on a multi-processor system or a multi-core system, more than one CPU may be used to complete a task. In this case, the CPU time may be more than the elapsed time.
Joined: 06 Jun 2008 Posts: 8165 Location: East Dubuque, Illinois, USA
Under z/OS, there are typically hundreds of tasks running simultaneously on any given system. These include started tasks (which would include DB2, MQ series, Websphere, system tasks), TSO users, batch jobs, CICS regions. The system manages these tasks and allows each to run for a certain amount of time each minute. CPU time is the amount of time the task is actually executed for while elapsed time represents the total amount of time the task has been around. The ratio between CPU and elapsed time can run from close to 1:1 (for a high-priority task running with no other work being done) to 1:100 (or higher) for a heavily loaded system with a low-priority task.
It may not be possible to fully describe all the factors that constitute elapsed time, but for a batch job here are some of them:
Number of jobs in system
Initiators in use
And there is a minimal correlation between CPU time and elapsed time. The exact same job can use the exact same about of CPU time and the elapsed time may vary by hours -- due to the above-mentioned factors, among others.
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
As has been mentioned before, elapsed time itself is not a "tunable" parameter.
Elapsed time can be altered by tuning (positively or negatively) things in the environment (like reducing i/o, gettng a faster cpu, tuning database design and query structure, and on and on and on) or by tuning specific things in the process itself.
One situation that i see more and more frequently is some "requirement" that causes thousands or millions of records to be handled 3, 5, or more times just allow the requirement to be met "with a jcl". Sometimes there are multiple utility and/or sort steps requiring incredible amounts of system resources just so some small bit of program code can be avoided.
And once implemented they will not perform satisfactorily. . . And have a major impact on other processes in the system.
Joined: 01 Sep 2006 Posts: 2086 Location: Silicon Valley
Judging by some of the questions in some of the forums, I think some people are writing rexx programs to schedule other jobs. I am assuming there is a lot of waiting for jobs to end. That is, in a scheme like that, the master would sleep most of the time, waking up every few minutes to see if a job ended. Elapsed time may be high, but CPU time low.