This comes from SMF type 30 subtype 2 and subtype 3 records. A subtype 2 record is written when an SMF interval expires - this may be the same as, or different to, the RMF interval time, and is set in the PARMLIB member SMFPRMxx . Subtype 3 records are cut to record the usage of resources between the last interval record to just before a job step ends. When Control Center reads a job interval record from Acquire it will apportion usage of CPU, I/O etc back across the RMF intervals where the job was running, in proportion to the amount of its elapsed time. This is similar to the job end processing but we only need to go back a smaller number of RMF intervals, maybe only 1. Here is the same job as previously with interval detail instead of job end data:
JOB1 starts at 21:33:24.17 and finishes at 22:29:43.54, an elapsed time of 00:56:19.37, or 3379.37 seconds. The single step that was run used 33.14 seconds of CPU time.
The job interval time is 30 minutes and is not synchronized with SMF, so a job interval record is cut at 22:03:24.17 showing the job used 7.45 seconds of CPU and a final interval record is cut at 22:29:43.54 showing it has used another 25.69 CPU seconds
The RMF interval time is 30 minutes or 1800 seconds, and appear at 21:30, 22:00 and 22:30
Control Center will take select the RMF intervals where the job was active and apportion the CPU time across them like this:
Using the interval record time at 22:03:24.17, we can see the job start time and note that it began in the interval 21:30 - 22:00, so
21:30 - 22:00 Job active for 00:26:35.84, or 1595.83 seconds.
CPU = 1595.83/1800.00* 7.45 = 6.60 CPU seconds
7.45 - 6.60= 0.85 seconds are considered to be in the next interval, in the remaining 00:03:24.16 of elapsed time.
22:00 - 22:30 Job active for 00:29:43:54 or 1783.54 seconds
CPU = 25.69 in this interval + 0.85 from the previous one = 26.54 CPU seconds
One benefit of using JOBS=I is that this chart is much closer to showing what actually happened. In addition, you have access to additional details - the step name and program name - which are not available from job end data, plus you will capture usage details from long-running tasks such as CICS, DB2 or system tasks that seldom end. A drawback of this is that your database will grow faster due to this additional detail.
Very Important Note!
By default, Acquire rounds up RMF times to the next nearest minute, and Precisely has seen examples of z/OS systems where the RMF time is consistently produced at say 40 seconds past the minute, with times like 21:29:40, 21:59:40, 22:29:40. Here our example job finishing at 22:29:43.54 is 3.54 seconds into a “dead zone", and Control Center will generate invalid, and possibly negative numbers in its apportioning. The INTROUND= parameter controls the rounding up of times, and the default is Y.
If you choose to capture job detail Acquire will force INTROUND=N to prevent from rounding up RMF times to the next nearest minute.