MVSFORUMS.com

[Annamalai]

Hi,
I want to know the factors deciding the CPU time and the elapsed time of a job.
The job reads an input file (avg of 2 million records) and writes four output files each based on different conditions.
I ran that job for four times. I got different values for the CPU time and the elapsed time for all of the four runs.

What is the reason for the varying values of CPU time and the elapsed time of the same job on different runs?

Thanks,
Annamalai

[kolusu]

Annamalai,

There are many things that can affect CPU time from run to run. Some of these relate to the other workload running in the system at the time. Busy CPUs (or CPUs that have to handle high numbers of interrupts from I/O) could increase your CPU time by causing the Translation Look-Aside Buffer to be flushed more often. If the physical memory is overcommitted, paging activity could cause your job to see longer CPU times. Also, some system calls could cause the system to scan through control block chains that might differ in length from run to run (for instance, memory control blocks, or enqueue control blocks). It would be unusual for CPU time differences to exceed 10% between runs due to this kind of cause.

There is a relationship between Elapsed (wall clock, or "real time") and CPU time. If at jobstep completion they are the same, then you'll know that your program spent no time being "swapped out", waiting for whatever resources to be available.

This is unlikely to happen, unless you're executing a load module under 4096 bytes in size that doesn't utilize any kind of I/O, or dynamically acquire any resources such as core storage. The IBM utility program IEFBR14 is one.

The program IEFBR14 is a dummy program as the name itself tells that the last 4 characters of the program name indicates what the program actually does, which is "branch to the address contained in general register 14", which means simply to return to the calling program. There is however, an extra instruction executed, which sets the contents of general register 15 to zero. However, such programs are of limited usefulness ,but IEFBR14 is more than a dummy program.

While processing files,it isn't contained within the program, so we have to tell the operating system about it.Usually, this is done in JCL, or via a TSO ALLOCATE command.Once the operating system has the file details, your program requests the first record. Internally, your program issues an Execute Channel Program(EXCP),and is immediately eligible to be "swapped out", or "put on hold",so other programs waiting to execute get their share of the processor's time.

Once your program gets "swapped out" waiting for resources, it won't be "swapped in" until your data record is available for processing, and other resources (such as core storage) are also available.

Finally when your data record is available, and the core storage is available, so your program gets "swapped in", you process the record, and then you write it to the output file. Internally, your program issues an EXCP to write the record... and your program is again eligible to be "swapped out".

The time difference is basically due to your program being "swapped out" due to requesting resources. CPU and "core" storage is quite a lot faster than DASD (several hundred times or greater) so it wouldn't make much sense to tie up the CPU, waiting for your data to become available (or written back to disk).Each program gets it's time with the CPU, when the resources are available.

Hope this helps...

cheers

kolusu

[semigeezer]

I don't know if IBM ever implemented it, but there were designs at one point for multiprocessing systems that had different speed CPUs. Your job's execution speed would differ depending on what CPU it got dispatched to. But even on similar CPUs, dispatching overhead will vary according to the other workloads in the system. I/O, retries, etc will all cause differences.